Unit Tests Summary

  1 files   23 suites   16m 8s ⏱️
155 tests 149 ✅ 5 💤 1 ❌
524 runs  518 ✅ 5 💤 1 ❌

For more details on these failures, see this check.

Results for commit f8b884f.

♻️ This comment has been updated with latest results.

Unit Test Performance Difference

Results for commit 9b0a1a2

♻️ This comment has been updated with latest results.

S3 methods can only dispatch according to one argument. This PR duplicates entire modules for a dispatch on one argument. Isn't it better to have a conversion or a warning on each argument? User might end up mixing the new and the old approach and that could throw off the dispatch mechanism.
Still this would require that some part of the module's code would need to change but I don't think it would be that much. Specially if the full release and removal of the old des object.

Isn't it better to have a conversion or a warning on each argument?

It is better, problem is that delayed-filter_spec (with value_choices()) are not convertible to teal_transform_module and thus we would have a breaking change.

I provided this "brute-force" solution to make sure nothing breaks. It is possible to implement filter_spec -> teal_transform_module conversion but it will require significant design intrusion. value_choices(subset = function(data)) where data is a data.frame - this will require delivering data.frame instead of vector from variables to values in order to support value_choices.

Instead of making a design compromise in resolver and determine.values, I would rather vote for changing filter_spec to support subset = function(column) instead.

Isn't it better to have a conversion or a warning on each argument?

It is better, problem is that delayed-filter_spec (with value_choices()) are not convertible to teal_transform_module and thus we would have a breaking change.

Yes, my idea is to raise an error when they are not convertible, and just a deprecation warning when they can be converted.

I provided this "brute-force" solution to make sure nothing breaks. It is possible to implement filter_spec -> teal_transform_module conversion but it will require significant design intrusion. value_choices(subset = function(data)) where data is a data.frame - this will require delivering data.frame instead of vector from variables to values in order to support value_choices.

Instead of making a design compromise in resolver and determine.values, I would rather vote for changing filter_spec to support subset = function(column) instead.

I am never sure of how to ease these transitions between code/designs. There are many tradeoffs and the most important information is hard to estimate: user current usage and user adoption of the future new design. How long we'll we need to keep value_choices and filter_spec working? Even if it is a breaking change it could be with teal.modules.* 1.0.0 release.

Yes, my idea is to raise an error when they are not convertible, and just a deprecation warning when they can be converted.

Yup, I'm not sure if soft-deprecation process should start with hard deprecating one of the components. But as a developer I'd be happy to have a single version of the tm_*

How long we'll we need to keep value_choices and filter_spec working? Even if it is a breaking change it could be with teal.modules.* 1.0.0 release.

Theoretically two minor releases. It could be more than one year. It would mean that during the most intensive development (in the early versions of the tool) we would have to deal with extra complication in the design. After the transition period we would remove and keep "raw" picks.